Timing transfer using a protocol such as IEEE 1588 PTP and a well designed slave clock recovery mechanism can provide time synchronization in the sub-microsecond region and lower. However, this is typically done using the important assumption that the time delay from master to slave is equal to that from slave to master.
In real life, the communication paths are not perfectly symmetric mainly due to dissimilar forward and reverse physical link delays and queuing delays. Even in cases where the physical link delays are known and properly compensated for during clock synchronization, queuing delays which are variable can still exist when timing messages go through the packet network and are queued for forwarding. The processing and buffering of packets in network devices (switches, routers, etc.) introduces variations in the time latency of packets traversing the packet network. This mainly happens when timing transfer is done in an end-to-end manner without any form of timing assistance from the network to help mitigate the effects of the variable queuing delays.
This “delay asymmetry” has become a major challenge in clock synchronization. The use of network timing support mechanisms such as boundary clocks (BCs) and transparent clocks (TCs) can eliminate delay asymmetry arising in the following scenarios [1][2][3]:                Dissimilar and variable queuing delays on forward and reverse paths (mainly due to different traffic load on the two traffic directions)        Asymmetry caused by timing packets taking different routes in each direction. This scenario is properly handled using peer-to-peer TCs. End-to-end TCs would not solve this kind of asymmetry.        
Note that to achieve this, the BCs and TCs have to be implemented on a node-by-node (hop-by-hop) basis from the timing reference source to the slave clock.
However, even these timing support mechanisms are unable to correct for delay asymmetry due to dissimilar physical links between network elements. This asymmetry arises because the forward and reverse paths are implemented in fibers or copper pairs in the same cable with each fiber in a pair having a different length. These fibers or copper pairs may have different lengths and different electrical or optical characteristics which are significant enough to create delay differences. The impact on time accuracy can be on the order of 2.5 ns per meter, with a 100 meter length introducing a 250 ns error. If this difference is not properly compensated, even with the use of BCs, a static time error can accumulate over a chain of BCs. Over multiple fiber links, the accumulated time error can become significant enough to exceed the very tight tolerances required by some applications such as those in mobile networks.
The above mechanisms are also unable to correct for delay asymmetries arising from the timing distribution inside an individual node. These time errors are due to various internal asymmetric delays when a time reference is being distributed from a centralized module in a node (e.g., system card) to other modules in a node (e.g., line card). These time errors arise, for example, due to the length of backplane traces, connectors, and various logic functions. Today, the best way to solve physical link asymmetry and asymmetry internal to a node is to manually calibrate links and internal timing paths. There is growing interests in automatic mechanisms for fiber link asymmetry compensation but these are under study.
IEEE 1588 PTP Message Flow
The IEEE 1588v2 PTP defines a packet-based synchronization protocol for communicating frequency, phase and time-of-day information from a master to one or more slaves with sub-microsecond accuracy. PTP relies on the use of accurately timestamped packets (at nanosecond level granularity) sent from a master clock to one or more slave clocks to allow them to synchronize (in frequency or time or both) to the master clock. Synchronization information is distributed hierarchically, with a GrandMaster clock at the root of the hierarchy. The GrandMaster provides the time reference for one or more slave devices. These slave devices can, in turn, act as master devices for further hierarchical layers of slave devices.
The PTP message exchange process (i.e., the PTP Delay Request/Delay Response flow) between a master and a slave is illustrated in FIG. 1 and described below.
IEEE 1588 PTP allows for two different types of timestamping methods, either one-step or two-step. One-step clocks update time information within event messages (Sync and Delay_Req) on-the-fly, while two-step clocks convey the precise timestamps of packets in general messages (Follow_Up and Delay_Resp). A Sync message is transmitted by a master 1 to its slaves 3 and either contains the exact time of its transmission or is followed by a Follow_Up message containing this time. In a two-step ordinary or boundary clock, the Follow_Up message communicates the value of the departure timestamp for a particular Sync message.
FIG. 1 illustrates the basic pattern of synchronization message exchanges for the two-step clocks. The master 1 sends a Sync message to the slave 3 over the packet network 2 and notes the time T1 at which it was sent. The slave receives the Sync message and notes the time of reception T2. The master 1 conveys to the slave 3 the timestamp T1 by one of two ways: 1) Embedding the timestamp T1 in the Sync message. This requires some sort of hardware processing (i.e., hardware timestamping) for highest accuracy and precision. 2) Embedding the timestamp T1 a Follow_Up message which is the sent to the slave (as shown in FIG. 1). Next, the slave 3 sends a Delay_Req message to the master 1 and notes the time T3 at which it was sent. The master receives the Delay_Req message and notes the time of reception T4. The master 1 conveys to the slave 3 the timestamp T4 by embedding it in a Delay_Resp message.
At the end of this PTP message exchange, the slave 3 possesses all four timestamps {T2, T3, T4}. These timestamps may be used to compute the offset of the slave's clock 5 with respect to the master clock 4 and the mean propagation time of messages between the two clocks. The computation of offset and propagation time assumes that the master-to-slave and slave-to-master propagation times are equal, i.e. that there is a symmetrical communication path. Clock frequencies change over time, so periodic message exchanges are required. Because these clock variations change slowly, the period between message exchanges is typically on the order of milliseconds to seconds.
An aim of the present invention is to provide mechanisms for compensating for asymmetries that are created by unequal queuing delays in the forward and reverse directions on a communicating path without using networking timing support mechanisms like BCs and TCs. Compensating for queue-induced asymmetries can eliminate a major source of clock errors particularly when timing messages traverse queuing systems in the packet network.
End-to-end time transfer is the most challenging problem in clock synchronization but also offers attractive benefits to the network operator. A further aim of the present invention is to provide methods and devices which offer transparency to the network where timing messages can cross different types of networks (Ethernet, MPLS, Packet of SONET, Frame Relay, etc.).